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EXECUTIVE  SUMMARY 


The  purpose  of  this  study  is  to  present  the  initial  Navy 
implementation  of  Department  of  Defense  Directive  5000.2°, 
"Management  of  Computer  Resources  in  Major  Defense  Systems". 

A critique  of  scope,  goals  and  applications  plus  summary 
recommendations  regarding  the  Directive  completes  the  study. 
Coverage  of  implementation  within  the  Department  of  the  Navy 
extends  to  tactical  weapons  systems  acquisition  and  deploy- 
ment. A brief  historical  overview  of  events  leading  to 
Directive  issuance  is  included. 
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SECTION  I 


INTRODUCTION 

Purpose  of  the  Study  Project 

The  basic  objective  of  this  project  is  to  provide  insight 
into  the  management  reaction  to  and  Implementation  of  a Depart- 
ment of  Defense  (DOD)  Directive  within  the  Department  of  the 
Navy.  The  project  was  undertaken  in  order  to  examine  the 
rapidly  underfolding  changes  in  overall  management  approach 
within  DOD  and  the  Navy  particularly  by  a current  investi- 
gation of  the  philosophies,  problems  and  systems.  The 
investigation  draws  heavily  on  interviews  at  all  levels 
within  the  Department  of  the  Navy,  supplemented  by  a survey 
of  available  literature. 

Scope 

This  report  is  limited  to  Navy  acquisition  management 
of  software  associated  with  weapon  3ystera3.  Software  asso- 
ciated with  weapons  systems  is  deployable  and  operational; 
this  represents  the  meaning  of  Embedded  Computer  Systems  (ECS) 
within  this  report.  The  contents  derive  largely  from  inter- 
views within  the  Assistant  Secretary  of  the  Navy  (ASN),  Chief 
of  Naval  Operations  (CNO),  Chief  of  Naval  Material  (CNM)  and 
Naval  Systems  Commands  (SUSCOXs),  as  current  actions  are  pre- 
cipitating from  these  levels. 
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Considering  the  formative  nature  of  the  topic  material, 
cut-off  date  of  15  October  1976  was  selected,  in  order  to 
support  report  submission  requirements;  interviewing  and 
literature  research  were  thu3  restricted.  Where  possible, 
trends  and  plans  are  noted,  with  the  full  understanding  that 
accurate  anticipation  of  future  events  is  impossible. 

The  original  intention  was  to  provide  clearly  separable 
statements  regarding  implementation  and  critique.  However, 
in  the  process  of  real  time  examination  of  Directive  scope 
and  impact,  the  formative  nature  of  the  implementation 
approach  was  clearly  predominant,  to  the  extent  that  imple- 
mentation and  critique  were  not  divorcible.  Therefore,  the 
critique  is  concerned  almost  exclusively  with  a DCD  perspec- 


SECTION  II 


BACKGROUND 

A brief  summary  of  those  events  instrumental  to  the  issu- 
ance of  DODD  5000.29  is  presented  here.  Only  major  events, 
studies  or  organizations  are  mentioned;  sufficient  sources  are 
listed  in  the  bibliography  to  permit  research  in  greater  depth. 
It  Is  also  noted  that  each  source  necessarily  draws  heavily 
from  his  own  background. 

If  current  real-time  tactical  weapon  systems  including 
software  capabilities  (taken  as  synonymous  with  Embedded  Com- 
puter Systems  (ECS)  for  purposes  of  this  study),  are  recognized 
as  having  materialized  and  rapidly  evolved  within  the  past 
decade  or  so,  the  generic  parent  still  must  be  regarded  as 
general  purpose  automated  data  processing  (ADP).  Regarding  ADP, 
general  government  concerns  (for  efficient  management  and  use) 
trace  from  the  mia-19503*  The  composite  of  these  concerns  were 
built  into  the  Brooks'  Bill;^1^  this  Bill  is  the  first  signi- 
ficant milestone  in  the  path  leading  to  promulgation  of  DODD 
50C0.29.  Also  in  1965,  OMB  Circular  A-71^)  marks  the  stated 
origin  of  Executive  3ranch  interest  in  effective  management  of 
ADP. 

Zompolich, ^ ) in  an  Industrial  College  of  the  Armed  Forces 
(ICAF)  study,  summarizes  DOD  developments  regarding  ECS  (also 
ADP  within  the  government)  through  the  early  1370s.  The  ECS 
chronology,  predominately  Navy,  highlights:  efforts  of  the 


Naval  Command,  Control  and  Communications  Automation  Prelim- 
inary Review  Group  (C-^APRG);  the  Reich  report  and  the  Navy 
Laboratory  Computing  Committee;  and  the  establishment  of  the 
Navy  Tactical  Automated  Data  Systems  Oft  ice  (TAD30,  MAT-Q9Y ) . 
Other  ECS  related  developments  within  the  Navy  during  the 
1960s  included  establishment  of  management  controls  regarding 
program  content.  Issuance  of  WS-b506  "Requirements  for  Digital 
Computer  Program  Documentat ion"( 4 ) and  formulation  of  Navy 
shipboard  and  airborne  automated  tactical  data  systems  standards 
(NTDS/ATDS),  relative  to  displays  and  communication,  as  in  ship- 
to-ship  communication,  are  examples. 

The  Pontius  study, (5)  a defense  Systems  Management  College 
Independent  Study  Project,  picks  up  the  chronology  essentially 
at  the  Completion  of  a prior  reference  (3)  and  delineates  events 
through  1975*  An  OSD  (IScL;  staff  study  ("Tactical  Computer 
Software  Acquisition  and  Maintenance,"  1973) and  the  two- 
phase  study  of  Management  of  Weapon  System  Software,  as  afforded 
by  the  MITRE^^  and  John  Hopkins  University/Applied  Physics 
Laboratory  (JHU/APL)^®)  area  studies  are  cited.  These  provide 
the  detailed  back-up  to  the  Directive.  Additional  investigatory 
efforts  leading  to  DODD  5000.29  include  those  of  the  Software 
Steering  Committee,  later  linked  to  the  Software  Reliability 
Work  Group  of  the  Joint  Logistics  Commanders. 

Most  recently,  the  major  precursor  of  DODD  5000.29  has  been 
the  Defense  Systems  Software  Management  Plan,^^  published 
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" March  1976.  The  Directive,  itself,  issued  26  April  1976. 
Subsequent  briefings  with  industry  include  an  AIAA  Seminar 
in  June,  1976.  Minutes  of  the  Seminar  provide  a broad  per- 
spective of  policy  guidance,  practices,  procedures  and 
actions  to  be  taken. (10) 


SECTION  III 


OVERVIEW 

DODD  5000.29  is  a collection  of  statements  regarding  ECS 
management  policy,  practices,  procedures  and  techniques.  The 
overall  intent  is  decentralized  management  within  a structured 
framework  of  operation,  consistent  with  the  requirements  for 
standardization  of  computer  resources . ( H)  The  Directive 
addresses  policy  in  seven  broad  management  areas:  validation 

and  verification;  risk  analysis;  configuration  management;  life 
cycle  planning;  support  software  deliverables;  milestone  defini- 
tion and  attainment;  and  software  language  standardization  and 
control. 

ECS  are  approached  by  the  Directive  through  a segmented 
definition  rather  than  by  a single  direct  definition:  embedded 

being  "integral  to,  from  the  design,  procurement  snd  operations 
point  of  view";  and  computer  systems  or  resources  being  "totality 
of  computer  equipment,  computer  program,  computer  data,  associ- 
ated documentation,  personnel  and  supplies." 

Though  the  Directive  is  limited  to  6 year3  effectivity,  the 
concept  itself  seem3  quite  durable;  the  microprocessor/dis- 
tributed system  of  the  near  future  is  penult imately  ECS,  both 
from  an  architectural  design  standpoint  and  from  the  ingrained 
tactical  system  procurement  philosophy. 

ECS  is  distinct  from  general  purpose  AD?  by  almost  any 
comparison  or  standard,  from  procurement  quantities  to 


compactness  and  ruggedness  of  design,  from  modularity  and 


flexibility  to  responsiveness.  Consequently,  a basic  premise 
of  the  Directive  is  that  the  Comptroller  function  of  ADP  pro- 
curement is  inappropriate  to  ECS.  Though  management  elements 
have  general  addressability  in  any  processing  system,  their 
relative  criticality  and  phasing  constraints  in  ECS  and  ADP 
are  sufficiently  variant  to  justify  separate  treatment  devel- 
oped in  the  Directive.  Evolution  of  ECS  since  the  mid-1960s 
has  further  defined  differences  with  ADP.  Accordingly, 
exclusions  from  5000.29,  including:  CM8  Circular  A-71;  DODDs 

l4.105»55*  4160.19  and  5100<,40  all  related  to  ADP;  as  well  as 
general  purpose,  commercially  available  ADP,  are  deemed 
appropriate. 

Though  Directive  scope  covers  major  Defense  programs, 
its  principles  are  appropriate  to  non-major  programs  as  well. 
Ultimate  integration  into  the  Weapon  System  Acquisition  is 
provided  through  absorption  into  DODDs  5000.1,  5000.2  and 
5000.3  prior  to  Directive  expiration;  in  the  interim,  biannual 
reviews  will  be  conducted  to  address  the  continuing  need  for 
5000.29  as  well  as  any  organizational  institutions  attached 
thereto. 

Responsibilities  are  cited,  c cmmensurate  with  the 
policy  and  practices,  with  emphasis  on  review  and  update  of 
existing  practices,  procedures  and  techniques.  Primary 
focus  in  this  process  is  the  D0D  Kanaeement  Steering  Com- 
mittee for  Embedded  Computer  Resources  (N'SC-ECR),  formerly 
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the  Weapons  Systems  Software  Management  Steering  Committee. 

DOD  component  inputs  to  the  Committee  are  to  include: 
guidance  documents;  personnel  training  and  career  paths;  and 
R&D  programs  via  Technology  Coordinating  Papers. 

The  style  of  the  Directive  is  similar  to  that  of  DODD 
5000.1.  Both  contain  a mixture  of  policy  and  practices, 
procedures  and  techniques.  Both  are  written  at  a very  high 
level  in  order  to  have  Tri-Service  applicability;  this 
necessitates  the  compact  format--5  and  7 pages  respectively. 

Each  represents  an  assimilation  and  gleaning  of  ideas  in  U3e, 
albeit  non-unif ormly , throughout  the  Services.  The  assimilation 
in  each  case  is  intended  to  provide  significant  adjustments 
and  consequent  improvements  to  the  acquisition  process. 

The  most  significant  change  aspect  relates  to  risk  reduc- 
tion in  the  total  sense.  Developmental  risks  are  to  be  scaled 
down  through  concentration  on  those  areas  of  high  risk  prior 
to  D3ARC  II  (inception  of  full  scale  development).  This 
combines  application  of  techniques  previously  successful  to 
hardware  (front-end  loading)  with  earlier  visibility  to  soft- 
ware to  regiment  risk  reduction.  In  that  same  vein,  operational 
requirements  are  to  receive  earlier,  fuller  visibility  and 
scrutiny;  the  user  is  to  De  involved,  though  not  deeply,  in  the 
Initial  design  phase,  perhaps  even  co-located  with  the  developer 
during  conceptual  and  validation  phases.  (12)  similarly,  PScD 
programs  will  be  examined  for  overall  balance  and  analyzed  in 
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terms  of  probability  of  validating  objectives.  All  these  points 
are  aimed  at  demonstrating  risk  reduction  through  the  DSARC  pro- 
cesses. 

Standardization  relates  to  minimization  and  avoidance  of 
proliferation;  a single  best  characteristic  of  ECS  may  not  be 
universally  appropriate,  however,  as  exemplified  by  considera- 
tion of  support  t ools • Also  in  this  category,  higher  order 
language  (KGL)  introductory  strategy  is  being  approached  from 
a timed  commitment  viewpoint,  based  on  inventory  resources, 
minimizing  overlap  and  availability. 
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SECTION  IV 


INITIAL  NAVY  IMPLEMENTATION 


Interim,  1975 

As  might  be  expected,  the  individual  Services  were  not 
totally  unprepared  for  the  issuance  of  this  Directive.  Through- 
out the  Navy,  existing  policies  and  practices  are  in  large 
measure  identifiable  with  the  Directive. 

In  1975  following  the  MIIRE  and  JKU  studies,  NAVMAT 
issued  a CAPSTONE  Directive  identifying  two  objectives:  sort 

out  basic  principles  of  software  management  appropriate  to  the 
forthcoming  DODD;  and  identify  R5cD  efforts  required  to  support 
essential  elements  of  DODD.  CAFSTONE  inputs  were  then  directed 
upward  through  OPNAV,  CNO,  ASN  and  eventually  to  DLPSECDEF  and 
the  D3APC  principals. 

Also,  in  1975»  in  the  area  of  conf izurat ion  management, 
0PNAVIN3T  4130.1  (Configuration  Management  of  software  in  sur- 
face ship  comnat  systems;  policies  concerning) ^3 ) was  issued, 
emphasizing  life  cycle  considerations,  interface  design  speci- 
fications and  maintenance  agencies.  Software  Conf izuratlon 
Control  Boards  (CCBs)  were  mandated,  including  identification  of 
the  roles  of  (subsystem)  Participating  Managers  (FARMS)  and  ship 
Logistics  Managers  (SLKs)  and  mechanics  of  Board  operation  and 
resolution  of  disagreements.  An  update  of  NAVXAT1NST  4130*2 
(Configuration  Management  of  Computer  software  Associated  with 


Tactical  Data  Systems  and  other  Technical  Computer  Systems)^^ 
was  drafted  for  consistency  with  0PNAVIN3T  4130.1. 

Conversion  of  non-standard  programs  to  standard  systems 
began  receiving  an  increasing  amount  of  consideration.  This 
consideration  involved  a cost-effectiveness  analysis  for 
deployed  systems,  as  well  as  a lessons-learned  forward  projection 
for  new  developments  in  terms  of  selection  of  system  language. 

In  terms  of  management  guidance,  preparation  began  in 
1975  on  MIL-STD-1679  (Tactical  Software  Development ); ^5)  in 
depth  discussion  cn  this  item  is  presented  in  a later  section. 

Validation  and  verification  became  an  accepted  discipline 
and  was  applied  to  the  AN/BQQ-5  program  among  others.  Soft- 
ware language  and  machine  standardization  and  control  had 
largely  stabilized  within  the  Navy  in  the  early  1960s  with  the 
introduction  of  CM -2  (Navy  standard  high  level  language)  and 
the  AN/lTi'K-7  (Navy  sbipborne  standard  computer)  so  that  minimal 
efforts  are  viewed  as  necessary  in  these  areas. 

Individual  SYSC0M3  expended  increased  attention  to  pre- 
diction and  control  of  software  development  costs  and  risk 
analysis.  In  particular,  a NAV3MA  study^1*3)  collected  data  from 
several  development  programs  with  the  objective  of  correlating 
mission  requirements  with  program  size  and  development  cost. 
Analysis  was  extended  to  functional  break-out  of  the  total  cost, 
to  operational  and  support  software  development  differences  and 
to  now  development  compared  with  update  of  existing  programs. 


Data  gathering  from  contractors  revealed  some  insight  into  the 
"black  art"  nature  of  estimating;  new  bids  derive  heavily  from 
past  experiences,  including  cost  growth  experience  (parametric 
estimation  is  largely  in  infancy).  The  necessity  of  discip- 
lining computer  system  development  in  cost  breakout  and  control 
of  milestones  is  stressed. 

Further  discussion  of  current  Navy  Implementation  is 
pursued  on  an  organizational  basis.  Principal  on-going 
actions  are  outlined  by  organization  in  Appendix  A. 


Assistant  Secretary  of  the  Navy  (A3N) 


At  this  level,  response  to  the  Directive  focuses  on 
development  of  a "family"  of  products  and  subsequent  enforce- 
ment to  the  basic  family.  A family  may  be  a Combat  System, 
such  as  an  aircraft  carrier  command,  control  and  communications 
(CV/c3)--  in  any  event  a platform-tie  is  indicated.  The  family 
consists  of  a standard  hardware  set, instruct i on  and  architect 
set  and  a designated  support  facility;  subsequent  enhancements 
are  attached  to  the  basic  family,  with  maximum  automatic  reduc- 
tion possible  and  desired.  Proper  enforcement  culminates  in 
full  potential  for  establishing  a later  second  source  capability 
and  permits  building  an  experienced  personnel  base  and  facility 
resource.  All  programs,  concepts  and  designs  are  thu3  to  be 
keyed  to  a requirements  and/or  platform  base.^?)  The  wisdom  of 
this  "keying"  is  apparent  based  on  recent  situations  in  the  All 
Applications  Digital  Computer  ( AADC ) and  in  the  Aegis  Program. 

The  RicD  strategy  is  one  of  moving  from  6.2  through  6.1+ 
in  an  integrated  fashion  in  order  to  output  basics  for  an 
improved  procurement  package.  The  family  concept  is  laced  in 
6.3  programs  with  design-to-price  intended  for  interfacing 
(different)  sensors  to  the  family.  A comprehensive  RicD  Plan 
is  targeted  for  completion  during  the  second  quarter  of  CY  1977, 
with  initial  factoring  into  the  FY  lu7&  budget. 

An  additional  element  of  response  is  the  stress  to  be 
placed  on  developmental  test  sites.  This  ties  in  well  with 
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risk  reduction  measures  (early  integration  efforts  leading  to 
earlier  problem  resolution),  while  at  the  same  time  comple- 
menting the  establishment  of  an  expertise  in  personnel  base  and 
providing  means  of  strengthening  career  and  training  objectives. 

The  next  significant  planned  item  in  test  sites  is  the  estab- 
lishment of  a CV/C3  test  site  at  NELC,  San  Diego,  presently 
scheduled  for  P0M-60  execution.  This  will  support  aircraft 
carrier  combat  suites  including  Tactical  Flag  Command  Center 
(TFCC)  and  National  Command  Authority  (NCA). 

Finally,  direction  from  ASN  to  CNM  has  gone  forward  to 
require  creation  of  a Deputy  Chief  of  Naval  Material  (DCNM) 
for  ECS  and  general  purpose  ADP.  This  will  be  further  ana- 
lyzed in  the  next  section. 


Chief  of  Naval  Operations  ( CNQ) 


Several  reorganizations  are  underway  or  planned  within 
the  Wavy  Doth  emanating  from  the  Directive  and  predating  it. 

In  June,  1975,  to  facilitate  improved  co-orainat Ion  and  control 
of  ECS,  OP-94  (previously  Command  Support  Program)  was  reorga- 
nized with  appropriate  responsibilities  and  authorities  and 
renamed  Director,  Command,  Control  and  Communications  Program. 
Since  that  time,  additional  changes  have  been  deemed  necessary 
and  restructuring  to  establish  Command, Control  and  Information 
Systems  Division  (OP-942)  reporting  to  0P-Q4  implemented.  This 
Division  will  bo  charged  with  the  execution  of  many  of  the 
functions  previously  under  Combat  Direction  System  Division 
(OP-034)  and  Information  Systems  Division  (OP-O^l).  Further, 
CP-5i|2  will  have  central  responsibility  for  providing  coordi- 
nation and  guidance  for  both  general  purpose  AD?  and  r,Cd 
computer  resources.  The  reorganization  was  approved  1 Octccer 
197o.  In  addition  certain  functions  resident  in  OP-034  were 
transferred  to  MAT-09Y;  this  change  has  not  yet  been  implemented 
and  further  discussion  is  postponed  to  the  next  section. 

Personnel  within  OP-034  and  OP-942  have  drafted  "An  Imple- 
mentation Plan  for  Computer  Resources  Management  In  Tactical 
Defense  System"^0)  in  response  to  the  Directive  at  the  request 
of  AdN  (RiD).  On  completion  and  approval  in  CNO  and  AdN,  the 
Plan,  which  will  outline  the  Wavy  approach,  will  be  forwarded 
to  A3D  (IiL).^^  Similar  responses  are  beinsc  developed  by  the 
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other  Services,  though  it  Is  believed  In  more  detail  than  the 

Navy  Implementation  Plan.  An  0PNAVIN3T  will  be  prepared, 

following  Plan  approval  by  ASD,  which  will  further  detail  and 

delineate  Navy  actions;  this  instruction  will  likely  Issue  in 

the  first  quarter  of  CY  1*577. 

The  Implementation  Plan  addresses  each  of  the  elements  of 

Section  V of  the  Directive.  Its  overall  intent  is  stated  as 

"to  provide  more  effective  performance  In  areas  such 
as  standardization  and  configuration  control  of  hard- 
ware and  software,  procedures  and  cost  for  development 
and  support  of  software,  personnel  performance,  and 
the  state-of-the-art  in  computer  resource  technology ." '*1 ) 

The  approach  is  thus  one  of  comprehensive  guidance,  with  an  aim 
of  flexibility  rather  than  undue  or  disruptive  constraints.  Th 
Plan  also  provides  coverage  for  the  Marine  Corps.  Systems 
within  Navy  Acquisition  Categories  I,  II  and  III  are  covered 
within  the  Plan;  general  purpose  ASP  is  excluded  as  in  the 
Directive.  Now  programs  are  obviously  effected,  though 
existing  programs  may  be  excluded  from  compliance  in  event  of 
significant  impact  or  disruption. 

To  provide  better  support  to  systems  intercommunicating 
through  automated  digital  data  links,  the  Plan  notes  that  estab 
lishment  of  a Naval  Tactical  Interoperability  Support  Activity 
(NTI3A)  has  been  proposed.  Such  an  agency  would  control  devel- 
opment, tost  and  maintenance  of  Navy,  joint  and  international 
interoperability  standards.  In  the  area  of  support  software, 
the  criticality  of  life  cycle  support  is  addressed  as  well  as 
concerns  for  the  AS ??.  language  of  "limited"  or  "restricted 
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rights".  Unlimited  rights  are  noted  as  necessary  in  develop- 
ments outside  Navy  standard  systems  and  CMi-2,  with  contractual 
coverage  to  so  reflect.  Tne  Navy  position  relative  to  Higher 
Order  Language  (HOL)  is  ooserved  rs  historically  well  Dased  and 
presently  consistent  with  DQD  attitudes.  Guidance  documents 
(MIL-SID-1679  and  Computer  Resources  Management  Manual)  are 
cited;  these  will  be  discussed  in  the  next  section.  Finally 
manpower  efforts,  including  training  and  personnel  needs,  and 
RicD  efforts  are  outlined  and  discussed. 
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Chi9f  of  Naval  Material  (CNM) 


Within  the  Naval  Material  Command  (NMC),  Directive 
related  actions  stem  principally  from  the  TADSO  Office  (MAT-Q9Y) 
and  from  the  R5cD  area  (MAT-03).  As  mentioned  in  the  last 
Section,  planning  has  been  initiated  effecting  TADSO,  through 
transferring  in  approrpiate  functions  to  establish  a more 
complete  sphere  of  responsibility,  consistent  with  desired 
control  and  through  corresponding  staff  increases.  Since 
other  factors  are  Involved,  such  as  ASN  direction  to  establish 
a DCNM  for  SCS  and  ADP  and  repeated  unsuccessful  planning 
efforts  regarding  estaolishing  a Computer  Systems  Command, 
planning  involving  TADSO  Is  still  incomplete.  As  an  aside. 

It  is  noted  that  among  other  Services,  the  Army  has  estab- 
lished a Computer  Systems  Command  (CSC)  at  Ft.  Eelvoir,  Va. 
However  the  current  major  Army  Command  and  Control  program, 

Army  Tactical  Data  Systems  (ARTADS),  has  since  been  chartered 
as  an  Independent  program  with  no  direct  working  arrangement 
with  CSC.  Thus,  apparently  establishment  of  a CSC  is  not  a 
panacea  in  terms  of  universal  problem  solution. 

The  TADSO  Office  is  directing  the  generation  of  guidance 
documents,  MIL-STD-1679  Tactical  Software  Development,^^)  93 
mentioned  earlier,  and  a Life  Cycle  Plan  which  is  based  on 
NAVA IR INST  5230.5. A draft  of  the  MIL-STD  was  released  in 
June,  1976.  The  first  review  cycle  has  been  completed  with 
many  comments  received  (including  a chance  of  document  number); 
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a revision  is  now  in  process.  This  document  relates  to  3 types 
of  tactical  software:  application;  test  and  maintenance;  and 

support.  Logistic  support  and  ADP  systems  are  excluded.  The 
Tactical  Data  Systems  Glossary  (March,  1G76)^U)  is  a referenced 
document,  containing  definitions  of  operational  and  technical 
terms.  The  MIL-STD  provides  guidance  through  General  and 
Detailed  -Requirements.  General  Requirements  briefly  address 
design  (performance)  changes,  standardization,  test  and 
development  visibility.  The  Detailed  section  is  rather 
explicit  in  terms  of  program  generation,  design,  standards  and 
conventions,  quality  assurance,  management  control,  etc. 
Requirements  for  Contract  Data  (most  items  taken  from  SLCNAVIN3T 
3560  and  for  transition  to  the  software  support  activity- 

are  portions  directly  attuned  to  DODD  50C0.29. 

TAD30  is  also  preparing  a Computer  Resources  Life  Cycle 
Management  Manual,  starting  from  a oa3e  of  the  NAVAIR  Plan  and 
making  appropriate  additions  and  modifications  to  provide 
general  application  within  NMC  and  all  SYSCOMs.  This  document 
Is  intended  to  guide  management  in  procedures,  structures  and 
contractual  matters,  including  a general  contract  data  require- 
ments list  (CDPL)  and  statement  of  work  (SCW).^^) 

MAT-03*  at  the  direction  of  A3N  (RlcD),  has  generated  NAYMAT 
Notice  54 20,  " NAYMAT  Council  for  R&D  in  Computer  Scionces. " ( 27 ) 
This  Notice,  to  ultimately  ce  superseded  by*a  NAYMAT INST , 
delineates  Navy  RjcD  philosophy,  approach  and  strategy.  First 
a top-down  validation  Plan  is  to  o?  established,  relating 
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objectives  to  proposed  efforts  and  proposed  efforts  to  specific, 
quantified,  time-scaled  tasks.  Priorities  for  undertaking  these 
tasks  are  then  set,  based  on  relevance,  objectives,  pay-cff, 
implementability  and  prooability  of  success.  Finally,  the 
specific  strategies  of  acquisition  management  research  are 
developed. ^ The  Council  itself  estaolishes  at  least  an 
appearance  of  centralized  management;  its  mission  is  one  of 
creating  balance  and  co-ordination  of  6. 1-6.1;  prcerams  and  of 
eliminating  redundancy.  The  Council  consists  of  five  committees 
with  the  following  functions:  setting  objectives  via  the  top- 

down  approach;  developing  machanisms  for  determining  priorities; 
microprocesscr/micro-cc.r.puter  standardization  (for  input  into 
SECNAV  or  NAVMAT  implementing  instruction);  technology  transfer 
(for  fleet  use);  and  developing  management  strategies.  An 
ir.tegrel  Council  function  is  document  review  to  include  Navy- 
Decision  Coordinating  Papers  (NLCPs),  Operational  Requirements 
(CRs),  Development  Proposals  (DPs)  and  Advanced  System  Concepts, 
again  striving  for  balance,  coordination  and  eliminating  redun- 
dancy. The  Council  Charter  also  calls  for  Designation  of  an 
R3cD  Program  Manager  for  Computer  Sciences. 

In  addition,  MAT-03  has  compiled,  again  at  the  direction 
of  ASN  (RfcD),  a tiraft  Plan  for  an  PicD  Program  for  Computer 
Resources  Management  in  Navy  System". (^9)  This  Plan  describes 
all  elements  within  6.1-6.U  Programs  as  well  as  setting  out  co- 
ordinated comprehensive  approaches.  The  Plan  is  anticipated  to 
complete  routing  to  ASN  (PiD)  for  final  approval  during  the  first 
quarter  of  Cl  1977. 
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Naval  Systems  Commands  (SYSCQMs) 


Naval  Air  ay  a terns  Command  ( NA7AI03Y  3COM  ) 

As  noted  in  the  two  previous  Sections,  NAVAIP  has  pro- 
mulgated Responsibility  and  Requirements  for  Preparation  of 
Software  Life  Cycle  Management  Plans  (SLCMP),  NAVAIRINST 
5230.5*  This  Instruction  provides  excellent,  comprehensive 
guidance  for  establishing  structured,  controllable  programs. 
Existing  programs  in  NAVAIR  are  to  be  reviewed  against  52J0.5 
for  consistency  and  necessary  updating,  without  necessity  of 
gross  formatting.  The  Flan  is  to  be  developed  prior  to  the 
issuance  of  the  Request  for  Proposal  (RFP)  for  full  scale 
development,  with  coverage  extending  to  three  subsequent 
phases:  development;  transition;  and  software  support  activity. 

A Software  Change  Review  Eoard  is  called  for,  with  Fleet 
participation  mandatory.  The  systems  engineering  proce33  is 
specified,  from  configuration  items  to  audits  and  baselines, 
from  system  analysis  (preliminary  and  Critical  Design  Reviews) 
to  independent  TicE,  Validation,  Verification  and  Certification 
(VVicC),  and  approval. 

In  the  area  of  standardizat  ion,  selection  of  and  initial 
procurement  contract  award  for  the  Standard  Airborne  Computer, 
AYK-I4  were  completed  In  September,  1-76.(30)  This  machine  is 
interface  compatible  with  another  Navy  standard,  the  UYK-20 
(shipboard  minicomputer).  These  steps  have  oeen  talen  to 


solve  the  prolil eration  proolem.  Extant  for  some  years, 
proliferation  can  largely  be  traced  to  classic  design  con- 
straints of  weight  and  volume  rather  than  commonality,  which 
now  has  been  accepted  as  the  premier  consideration. 


Naval  electronics  Systems  Command  (NAVELEX) 


All  SYSCGMs  are  supporting  the  RdcD  Council  and  are  pro- 
viding participants  to  various  committees.  Perhaps  NAVELEX 
has  the  heaviest  involvement  in  both  Council  and  Committee; 
certainly,  drafting  of  the  Plan  for  R&D  Program  and  estab- 
lishing the  Council  were  efforts  involving  significant  expen- 
ditures on  the  part  of  EL3X  personnel  in  support  of  MAT-03. (31) 
NAVELEX  continues  to  support  CNM  in  the  control  and 
maintenance  of  the  family  of  standard  compilers  (CKS-2M, 

CM3-2Q,  CMS-2Y).  In  the  area  of  language  standardization 
efforts  on  CHOICE  and  CS-U  that  ELEX  had  participated  in 
have  terminated  in  favor  of  DOD-1  under  the  control  of  DC  D. 

This  information  i3  believed  largely  incomplete  pre- 
sumbably  due  to  the  state  of  flux  within  NAVELEX  presently 
and  to  the  limited  number  of  persons  contacted. 


Naval  Sea  Systems  Command  ( NAV S2ASYSC0M ) 


NAVSEA  personnel  have  promulgated  several  documents  keyed 
to  Improvement  of  management  control  of  software  development: 
REiiP  POINTS  (Ship  Acquisition),  September,  1976;(32)  Acquisi- 
tion Process  Instruction; ( 33)  Combat  Systems  Design  Require- 
ments and  Operational  Design  Instruction; (-4)  and  Combat 
System  Computer  Program  Guidance  for  Ship  Project  Directive 
and  Training. ( 35) 

The  content  of  the  third  document  is  briefly  analysed 
here.  Combat  System  Design  Requirements  ( CSDP ) and  Operational 
Design  (CSOD)  are  taken  as  the  basi3  for  combat  system  inte- 
gration, scheduling  and  fiscal  planning;  a premium  is  accord- 
ingly placed  on  this  documentation  for  the  conceptual  design 
phase  as  well  as  for  3uosequont  management  visibility  and 
tactical  use  and  training. 

To  hotter  control  the  significant  differences  in  ship 
acquisition  compared  to  other  Naval  Acquisition  processes , (36 ) 
NAVS2A  is  pursuing  an  RSeD  effort  known  as  PATHWAYS,  The 
major  product  with  development  applicability  is  intended  to  be 
an  "off  the  3helf"  Software  Quality  Control  Manual,  based  on 
poll 3 of  lessons  learned.  Studies  thus  far  conclude  that 
quality  assurance  of  shipboard  installed  computer  programs  is 
characterized  by  three  factors:  correctness;  ease  of  modifi- 

cation and  tronsf era bility . ^ 37 ) The  basic  tenor  of  PATHWAYS 
is  being  pursued  as  an  addendum  to  the  Draft  Plan  fcr  an  R*R 
Program  for  Computer  Resources  Management  In  Navy  systems, 
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SECTION  V 

evaluat  ion/ cri  r io.ue 


» 


Operations  of  the  N3C/ECR  will  undoubtedly  determine  the 
ultimate  effectivity  of  DOCD  5000.29.  The  Committee  is  tiered 
into  2 components  in  order  to  insure  objectivity  and  appropriate 
consideration  of  alternatives.  The  existence  of  this  body  of 
a large  numcer  of  knowledgable  people  guarantees  visibility 
of  and  attention  to  ECS  at  higher  levels  of  authority;  tangible 
policy  and  advisory  output  to  DDRScE  and  D3ARC  principles  are 
the  specified  means  of  communication.  Nonetheless,  this  pro- 
cess can  be  aDused  through  Committee  stagnation,  with  resulting 
ineffective  decisions  and  further  lagging  of  overall  implemen- 
tation of  effective  program  management  control.  Effectiveness 
of  the  Committee  will  therefore  depend  on  its  receptivity  and 
selectivity. 

The  time-limited  absorption  into  DODD  5000. 1,  5000.2 
and  5000.3  is  also  of  concern.  In  fact,  since  the  concepts  of 
5000.29  were  not  initially  directly  written  into  modifications 
of  these  three  Directives,  the  status  of  the  concepts  is 
somewhat  compromised  from  inception.  If  successful  hardware 
development  and  life  cycle  practices  are  directly  applicable 
to  software  as  hypothesized,  the  intermediate  step  of  5000.2° 
could  certainly  be  argued  superfluous. 

A comparison  of  the  Directive  to  the  two  phase  study  of 
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KIT PE  and  JKU/APL  reveals  that  content  is  largely  common; 
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however  the  two-phase  study  adaresses  the  areas  of  Program 
Manager  support,  software  test  tools  and  software  work  break- 
down structure  (WB3)  without  corresponding  coverage  in  the 
Directive.  These  later  two  items  are  obviously  the  only 
concerns  for  purposes  of  this  study.  Mention  of  software 
test  tools  in  the  Directive  is  restricted  to  the  deliverable 
context,  without  attention  to  the  development  function  and 
attendant  risk  reduction  value.  WBS  presumbably  has  appli- 
cation at  the  General  Policy  level,  certainly  as  a Life 
Cycle  Planning  basic  consideration. 

The  basic  purposes  of  separating  ADF  and  ECS  are  sum- 
marized as  follows:  criticality  of  performance  with  corre- 

sponding demands  for  reliability  and  maintainability; 
responsiveness  to  changing  operational  requirements,  demanding 
change  efficiency  and  supporting  detailed  documentation;  and 
management  of  life  cycle  cost3,  requiring  careful  attention  to 
design  factors  and  intersystem  standardization  restrictions. (36) 
A significant  portion  of  the  Directive  rests  on  the  division 
and  maintaining  separation  of  ECS  and  ADP  disciplines;  the 
validity  of  this  thesis  has  not  and  perhaps  cannot  be  exhaus- 
tively evaluated.  Nonetheless,  the  areument  for  separation  has 
been  accepted  by  virtue  of  promulgation  of  the  Directive  and 
the  test  for  its  effectiveness,  with  full  visibility  and  control 
techniques,  set  in  motion.  To  gain  objective  and  fair  results, 
the  thesis  must  be  tested  in  the  environment  of  its  creation. 
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Subsequently,  based  on  the  test  results,  present  substance  must 
be  supplemented  and  advisory  comments  further  defined.  Gen- 
erally, a two-pronged  assault  of  discipline  and  understanding 
must  be  applied. 

The  Directive  speaks  to  "correctness  of  software"  and 
"conformance  of  . . . resources  with  stated  operational 
requirements."  Though  only  generally  descriptive,  these 
elements  relate  to  lessons  learned,  thereby  emphasizing  past 
mistakes.  As  a technical  area  matures,  a specific  checklist, 
rehashing  problems,  can  De  exonerated.  ( 39 ) However,  there  is 
no  guarantee  that  these  elements  or  combinations  thereof  ere 
germane  for  future  developments  or  efforts.  In  this  sense, 
the  approach  is  restrictive. 

In  terms  of  personnel  and  training,  current  problems 
seem  somewhat  more  complex;  ICS  demands  a dual  skill,  one  not 
readily  available  through  formal  education,  but  one  gained 
through  on-the-job  training. ^0)  Traditionally,  these  same 
specialized  skills  of  the  software  engineer  have  been  met  with 
restricted  promotional  perspectives;  on  the  other  hand,  a 
centralized  computer  management  organization  has  not  been 
acceptable  to  the  specialist  either. These  skills  are 
essential  to  concept  formulation,  validation  and  contract 
definition. 


One  of  several  intents  of  the  ’Vrective  is  to  provide 
front  end  loading  in  the  interest  of  subsequent  life  cycle 
savings  and  mere  effective  system  capabilities.  The  process 


is  one  of  endoctrination:  education  of  the  PM  to  properly 

plan,  analyze  and  request  the  necessary  development  funds; 
and  to  evince  a credibility  accompanying  the  capability  of 
proper  management  to  support  the  appropriation  of  these 
funds.  A history  of  incurring  design  expenses  to  save  life 
cycle  costs  must  be  achieved  to  support  this  process.  In 
all  livelihood,  this  process  is  not  only  cost-effective,  but 
in  light  of  recent  trends  in  ECS  cost  history,  mendatory. 


SECTION  VI 


RECOMMENDATIONS 

Navy  implementation  is  presently  directed  toward  responding 
to  the  Directive,  toward  preparation  of  a balanced,  non-recun- 
dunt  R3cD  plan  and  allocation,  and  toward  identification  of 
responsible  organizations,  performing  under  appropriate  charters. 
These  approaches  are  all  necessary;  the  test  of  their  effectivity 
lies  in  how  well  the  organizational  changes  promote  better 
understanding  and  communication.  A particular  instance  is, 
those  joint  programs  or  programs  involving  different  SYSCCH3 
which  must  provide  better  co-ordination  in  terms  cf  operator 
interfaces  and  life  cycle  support  planning.  The  Directive 
doe3  not  explicitly  treat  this  area;  an  early  revision  is 
believed  useful  to  indicate  relevance. 

Successful  programs  invariably  can  be  traced  to  effective 
understanding  and  consistent  discipline. Consequently, 
perhaps  the  most  important  actions  the  Navy  can  now  take  in 
compliance  to  the  Directive  relate  to  prompt  completion  and 
distribution  of  the  guidance  documents,  a means  of  maintaining 
those  documents,  of  insuring  that  all  managers  have  and  con- 
tinue to  have  access  and  finally  providing  a central  point  to 
dispense  authoritative  supplemental  guidance  in  unique  instances 
as  the  needs  inevitably  arise. 

Several  years  ago,  the  Department  of  the  Navy  incurred  a 
substantial  expenditure  to  improve  hardware  reliability;  in 
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to 


have  been  warranted 


A 


large  measure,  this  effort  appears 
key  ingredient  in  this  effort  was  estaolishment  of  a high  level 
czar  ( DCNM  for  Reliability  and  Maintainability).  If  the  Navy 
is  seriously  concerned  about  current  widespread  proolems  in 
ECS,  creation  of  another  czar,  addressing  only  ECS  problems, 
would  seem  to  be  a legitimate  starting  point. 

Current  approaches  to  the  personnel  problem  (training  and 
career  paths)  have  not  proved  successful;  this  situation,  in 
fact,  has  worsened  over  time.  Alternative  approaches  must  be 
formulated  and  evaluated.  In  particular.  Defense  Systems 
Management  College  should  take  a lead  role  through  curricula 
changes  and  through  research  of  alternative  approaches. 

Finally,  RScD  efforts  should  Include  investigations  of 
top-down  constraint  approaches  to  supplement  the  lessons- 
learned  techniques  to  counter  original  problems  in  future 
developments. 
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